home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc718.txt < prev    next >
Text File  |  1994-08-01  |  4KB  |  116 lines
  1. Network Working Group                                     Jon Postel  (SRI-ARC)
  2. Request For Comments: 718                                              Jun 1976
  3. NIC #35874
  4.  
  5.  
  6.  
  7. The following memo was a page of a document describing changes in
  8. version 1.34 of the Tenex system. I believe that the author is Ray
  9. Tomlinson or someone else in the BBN-RCC Tenex group. In any case Ray
  10. has agreed that these comments should be circulated to the to the
  11. network community, rather than to only the Tenex community.
  12.  
  13.  
  14.          Comments on RCTE from the TENEX Implementation Experience
  15.  
  16. The code to implement the RCTE option of the new TELNET protocol for
  17. TENEX has been completed. The RCTE option permits a reduction in network
  18. traffic by deferring the transmission of characters which will not cause
  19. the receiving user program to be activated until a character which will
  20. cause the user program to be activated. A further reduction is achieved
  21. by minimizing the flow of echo characters back to the user TELNET
  22. program. This is done by having the server instruct the user TELNET to
  23. echo the group of characters up through the next wakeup character. By
  24. sending this command as the user program is about to read the first
  25. character of that group, the echo is guaranteed to follow any response
  26. to the preceding group of characters.
  27.  
  28. Significant problems with the RCTE protocol were encountered. The
  29. handling of spontaneous output was specified in a way that made the
  30. implementation extremely difficult to do correctly (if, indeed, a
  31. correct implementation is possible). The solution here was to completely
  32. isolate the control of input transmission and echoing from the
  33. characters flowing in the output stream. Synchronization of input and
  34. output then occurs directly by virtue of the embedding of control
  35. information in the output stream. This approach permits a simplified
  36. coding of both the user TELNET and server TELNET.
  37.  
  38. A second problem was the handling of interrupt characters. The RCTE
  39. protocol fails to provide an explicit mechanism for interrupt characters
  40. thus necessitating the handling of interrupt characters as program
  41. wakeup characters. Since the interrupt characters are not actually
  42. handled as program wakeup characters and, in fact, bypass the terminal
  43. input buffer, a special provision had to be made to get the command sent
  44. back to the user TELNET to indicate that the character stream should be
  45. echoed beyond the point where the interrupt character was typed. The
  46. transmission must be synchronized with the processing of the terminal
  47. input buffer so that it will be sent at the proper time. This was
  48. achieved by putting a marker in the input buffer at the point where the
  49. interrupt character was. This marker is never given to the user's
  50. program and must not be counted as an input character. A new counter was
  51. installed indicating the number of such markers in the input buffer and
  52. the SIBE JSYS modified to indicate "empty" only if the difference of the
  53. total characters in the buffer and the number of markers in the buffer
  54. is greater than 0.
  55.  
  56.                                    -1-
  57.  
  58.  
  59.  
  60. A third problem is handling the case where the input buffer is cleared.
  61. Since the buffer may contain various wakeup characters and special
  62. markers, when the buffer is cleared, the user TELNET and SERVER may get
  63. out of sync. It is infeasible to scan the buffer and send a RCTE
  64. command for each such wakeup character or special marker. instead, a
  65. command is sent to the user TELNET meaning "clear your input buffer and
  66. reset your counters". This command is implemented by sending "WILL
  67. RCTE". This is the reverse case from a normal RCTE (i.e. DO RCTE) and
  68. thus cannot be confused with the normal use of the RCTE option. This
  69. saves adding a new option.
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.                                    -2-
  116.